Todo lo que deberías saber sobre Linux y MySQL y nunca te atreviste a preguntar

Yoshinori Matsunobu es Principal Infrastructure Architect en DeNA, habiendo sido previament MySQL Lead Consultant en MySQL/Oracle/Sun, aunque ahora he visto en su blog que es Oracle ACE Director. Hace unas semanas me topé con unas transparencias de un tutorial de 3 horas que dió en la MySQL Conference and Expo 2011, y que sin ninguna duda es la biblia de MySQL y Linux.

Los problemas de NoSQL

A través del Twitter de Miguel Ángel Pastor, ya mi referencia para estar al tanto de los temas de escalabilidad, llego a estas interesantes reflexiones sobre NoSQL que se publican en High Scalability.

Aparentemente, según comentan en el artículo, se están leyendo cada vez más opiniones negativas de personas que se han dado cuenta que no es oro todo lo que reluce dentro del mundo de NoSQL. Algo que por otra parte, tampoco nos debería extrañar a nadie ya que hay muy pocas tecnologías que sean sólo ventajas.

Hadoop y Hbase en Last.fm

La pasada semana este blog estuvo parado ya que estuve casi todos los días en Londres. Allí tuve la oportunidad de tomarme unas pintas con David Hernandez y Marc de Palol, ambos unos cracks que se encuentran viviendo y trabajando en la city.

El blog de David ya lo conocía. El que no conocía era el de Marc. Entre pinta y pinta estuvimos comentando como estaba la situación de los dos países, y muchos otros temas. Uno de ellos era como todos veíamos que Hadoop estaba dando fuerte y como se empezaba a usar más y más, también en España.

Sharding, ¿sí o no?

Facebook, Digg y muchos otros utilizan una técnica denominada Sharding para escalar.

El Sharding es una técnica que consiste en particionar los datos de tu base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento más rápido. Una agrupación típica puede ser por id por ejemplo: "los usuarios del 1 al millón están en esta base de datos"; o por nombre "los usuarios cuyo nombre va de la A a la E" están en esta base de datos".

Típicamente estos shards, agrupaciones o segmentos estarán localizados en tablas en diferentes bases de datos y localizaciones físicas. El Sharding no tiene por qué estar basado únicamente en una tabla y una columna, puede ser a nivel de todas las tablas. Por ejemplo podríamos decir "todos los datos de usuarios cuyo perfil está en los Estados Unidos los redirigimos a la base de datos del servidor en Estados Unidos, y todos los de Asia van a la base de datos de Asia".

El Sharding como tal mejora la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas por lo que los accesos serán mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, el basar el Sharding en la localización geográfica permite también disminuir considerablemente la latencia.

¿Cuándo se necesita hacer Sharding? Principalmente cuando el volumen de datos comienza a ser inmanejable. A tablas más grandes, más lentos son los accesos. No es lo mismo acceder a una tabla de diez mil usuarios que a una tabla de diez millones de usuarios. También comentan en el blog del que hablaré en breve que es bueno hacer Sharding cuando el volumen de escrituras es demasiado grande para un único servidor. En bases de datos, escrituras=bloqueos, bloqueos=contención de recursos, contención de recursos=mala experiencia de usuario, a parte del problema con la sincronización con slaves.

Todo esto viene a cuento de que en el blog de rendimiento de MySQL nos advierten de por qué no deberíamos hacer Sharding prematuramente. El problema principal es que Sharding se ha convertido en una palabra de moda. A fin de cuentas, si Facebook lo hace, ¿por qué no lo voy a hacer yo? Pues porque yo no tengo 120 millones de usuarios activos, ¿quizás?

Mi opinión es que en general estoy de acuerdo con el no hacer Sharding desde el principio, pero sólo si este va a impactar en la estructura de la base de datos. Es decir, dividir los usuarios de la A-E, la F-M, ... etc. a bote pronto parece como una mala decisión, al menos sin saber si vamos a tener cien usuarios o cien mil.

Pero planificar para Sharding no siempre tiene por que ser una mala decisión. En Java por ejemplo hay herramientas que nos lo facilitan. En general, el particionar por aplicación o por país además no son decisiones demasiado relevantes y que no tienen porque impactar el desarrollo en sobremanera, al tiempo que en el futuro facilitan enormemente la escalabilidad del servicio. Eso sí, hay que tener claro que a mayor número de shards mayor mantenimiento. No es lo mismo actualizar un índice en una tabla que hacerlo en cinco, especialmente porque al hacerlo en cinco es más fácil el dejarse uno olvidado.

Más sobre Facebook. Esta vez, Hadoop y datawarehousing.

Hoy, repasando los feeds pendientes de leer, me he encontrado con este artículo sobre Facebook y Hadoop.

El artículo está muy bien hecho y todo su contenido vale la pena, así que recomiendo su lectura. Básicamente comenta como en el 2007 Facebook decidió migrar un datawarehouse (de un vendedor que no menciona) de 15 terabytes a Hadoop. Las razones eran varias: precio de las licencias, menor coste de hardware, más rendimiento al no tener necesidad de transacciones, o la capacidad del equipo de Facebook para contribuir al Open Source.

Para el sistema de datawarehouse utilizaron Hive. Es interesante mencionar que la estabilidad del sistema no es perfecta, pero que parece que a los usuarios no les importan que se caigan nodos o que las consultas puedan tardar hasta 1 hora en devolver datos siempre y cuando no tengan que enviarlas de nuevo.

Por cierto que en otra nota en el mismo blog hablan del uso de compresión gzip que hace Facebook. Me apunto este blog de DBMS2. Parece un gran recurso.

Por cierto que por si os interesa, os dejo enlaces a estos dos posts que ya había escrito anteriormente sobre la arquitectura de Facebook y el uso que Facebook hace de Hadoop:

Notas sobre la arquitectura de Facebook.
Hadoop@Facebook.

PostgreSQL@Skype

Vía High Scalability llego a un interesante artículo sobre como usan PostgreSQL en Skype.

La verdad es que sí que es cierto que PostgreSQL es uno de esos grandes olvidados en el mundo las bases de datos. Durante toda su historia ha estado completamente eclipsado por MySQL. Todo el mundo reconoce que su motor es mejor que MySQL, pero mires a donde mires la gente usa MySQL en vez de PostgreSQL; seguramente sea la mejor base de datos Open Source, pero MySQL consiguió tener su propia compañía gerando enormes beneficios; y para colmo, su creador trabaja en Sun, pero Sun compra MySQL.

Por eso probablemente este artículo sobre Skype, y conocer que una de esas empresas tecnológicas high-profile está utilizando PostgreSQL es especialmente interesante.

En el artículo, comentan como contrataron a un equipo de consultores para analizar su base de datos en busca de soportar 1 billón de usuarios concurrentes. Como esa carga sería muy superior a la que soportaría cualquier superior, escogen una aproximación de sharding en función del código de usuario y escalan horizontalmente añadiendo nuevos servidores.

Lo más curioso es la aproximación utilizada para el sharding, y es que Skype realiza todo el acceso a datos utilizando procedimientos almacenados. Incluso han creado su propio lenguaje PL/Proxy. En el artículo, comentan que esto ha sido una decisión clave y muy exitosa ya que les ha permitido realizar inmensas optimizaciones de rendimiento simplemente modificando los procedimientos almacenados.

Llegados a la hora de escoger que servidor de base de datos servirá una petición determinada, la elección se realiza también en los procedimientos almacenados utilizando su lenguaje especial:

CREATE FUNCTION pwd_check(text, text) RETURNS boolean 
$$
  CLUSTER userdb_cluster;
  PARTITION BY hashtext($1);
$$ LANGUAGE plproxy;

Sucio. Sí, probablemente. Pero efectivo al máximo.

Por cierto, que navegando un poco por su web he visto un par de enlaces interesantes con montones de recursos para integrar Skype dentro de nuestras aplicaciones:

• Skype Garage, una especie de incubador de proyectos experimentales.


• Skype Developers Zone, su nombre lo dice todo.
  
• Skype Developers Zone Blog, el blog de desarrolladores.

Round Robin Databases

El año pasado por un requerimiento del trabajo me encontré on una herramienta que nunca había visto antes. Se trata de RRDTool. En su momento iba a postear sobre ello pero me imaginé que era algo bastante conocido ya que parece que mucha gente de sistemas está familiarizada con este tipo de herramientas. Hace unos días me encontré con un requisito que se ajustaba a este tipo de soluciones y la gente tampoco conocía el concepto por detrás de RRDTool, así que supongo que no está de más guardar el conocimiento por aquí.

RRDTool es una herramienta construida sobre el concepto de Round-Robin Database. Se trata de un tipo muy específico de base de datos, orientadas al almacenamiento de datos basados en series temporales, y que garantizan el espacio final ocupado por sus elementos.

RRDTool es muy sencillo de utilizar, y probablemente con un ejemplo se entienda mejor como funciona. Imaginaros un sistema de análisis bursátil. Cada día, una cotización puede variar de valor unas cuantas veces por segundo. Imaginémonos que varía 3 veces por segundo. Esto significa que en un día, asumiendo un intervalo de trading de ocho horas, se tienen 8*60*60*3 = 86400 valores por día. Si asumimos por ejemplo 100 valores a seguir, tendríamos 8640000 cotizaciones al día, lo que son casi 10 millones. En una semana (de 5 días), andaríamos cerca de los 40 millones de valores, y en un mes laboral rondaríamos los 200 millones.

Ahora bien, ¿a quién le interesa el valor que tenía la acción de Endesa en el segundo 20, del minuto 35, a las cuatro de la tarde del 21 de Enero del 2008? Respuesta simple: a nadie. Comúnmente la granularidad fina en los datos temporales es sólo interesante en una ventana corta de tiempo. Por ejemplo en un sistema de seguimiento de transacciones, interesa saber que ha fallado una transacción en las pocas horas, pero pasados los meses la información de exáctamente cuándo deja de perder importancia (sigue teniendo importancia el saber que hubo un fallo, pero ya no importa si en lugar de minutos nos quedamos con el día).

Lo que hace RRDTool es agrupar la información conforme a intervalos de tiempo que nosotros definimos. Por ejemplo, le podemos decir que queremos que guarde los datos con una granularidad de 1 segundo para la primera hora, con granularidad de 5 minutos, para las siguientes 23 horas, con granularidad de 30 minutos para 1 semana, 1 hora para los tres primeros meses, y 1 día para los últimos 9 meses del año. Al introducir datos en RRDTool, la herramienta se encarga de realizar las agruaciones y las medias conforme a los intervalos que hemos definido.

Seguramente, incluso los que no habíais oído hablar del concepto de Round-Robin Database ya os habríais encontrado con estos sistemas hace tiempo. En la página web de RRDTool tienen una amplia galería de ejemplos, pero si vais por ejemplo a Yahoo Finance (por poner un ejemplo) veréis como para mostrar las gráficas, la granularidad de los valores de una acción dependen del tipo de intervalo que escogéis: 1 minuto para el día, 5 minutos para 5 días, 1 día para el intervalor de 1 mes, etc. Se trata de economizar información.

En su web tienen bindings para lenguajes como Python y Ruby. Para los javeros, existe una implementación 100% Java de RRDTool: rrd4j que yo he probado y funciona bastante bien.

Pues nada más por hoy. ¡Espero que esto le sea útil a alquien!

El nuevo motor de almacenamiento de MySQL se llama Maria

Vaya nombre ha escogido Michael Videnius para lo que es el nuevo y reluciente motor de almacenamiento MySQL. Según comenta en su blog, aunque el trabajo lo comenzaron hace un par de años, sólo ha sido en los últimos cuatro meses cuando se han puesto realmente serios con él.

Maria viene a sustituir al ya vetusto y siempre criticado MyISAM, pero no será parte estándar de las distribución hasta MySQL 6.0. La idea es la de proporcionar un motor rápido y compacto como MyISAM para modos no-transaccionales pero al mismo tiempo solucionar las carencias de éste como son la falta de transaccionalidad. Pero eso todavía será para Maria 2.0. Por ahora la versión que han lanzado es una alternativa a MyISAM pero con tolerancia a caidas del servidor.

Muchos bloggers se han hecho eco de esta noticia, aunque creo que no demasiados sitios web ya que sólo he visto la noticia en Artima. Kevin Burton comenta por ejemplo que al menos tenemos una opción más, aunque habrá que esperar hasta que podamos tirar a la basura MyISAM e InnoDB. Por su parte, Colin Charles y Giuseppe Maxia han han estado intentando romper Maria pero parece que realmente el motor sobrevive a fallos.

La verdad es que el motor promete bastante. A ver si con suerte, ahora que Sun Microsystems está detrás de la compañía quizás esto avance incluso más rápido.

¿Es MapReduce un paso atrás?

La gripe que inevitablemente estoy incubando sumado a que llevo unos días un poco desconectado debido al esfuerzo de arrancar algo del que probablemente pronto tengáis noticia y que me tiene muy ilusionado, me ha hecho mantenerme un poco apartado del blog estos días y también de las noticias blogosféricas. Y claro, hoy al ir repasando mis feeds me he encontrado con el tremendo lio que se ha montado debido al último artículo de Michael Stonebraker: MapReduce: A major step backwards.

StoneBraker es una referencia dentro del mundo de la base de datos. Recientemente, uno de sus artículos tubo enorme aceptación al cuestionarse si las bases de datos relacionales habían quedado obsoletas en un mundo en el que las bases de datos especializadas tenían cada vez más éxito. Sin embargo, parece que ahora ha dado con un hueso muy duro de roer con la comunidad de la computación distribuida.

StoneBraker afirma en su artículo que MapReduce es un enorme paso atrás en la computación distribuida, en base a los siguientes argumentos:

• Representación de datos anticuada. No aprovecha los conocimientos adquiridos en los últimos años y las ventajas de utilizar esquemas y lenguajes de acceso a datos de alto nivel.
• Una aproximación menos que óptima basada en fuerza bruta.
• Nada nuevo, ya existía hace 25 años.
• Adolece de la falta de la mayor parte de funcionalidades disponibles dentro de las bases de datos relacionales.
• Es incompatible con todas las herramientas disponibles para bases de datos, es decir generadores de informes, herramientas de BI, data mining, data warehousing, etc.

Prácticamente todos los medios de noticias y bloggers están de acuerdo en que StoneBraker ha cometido un error muy básico, que es comparar peras con naranjas, bases de datos con algoritmos de computación distribuida.

Hay quien trata de exponer todos los errores del artículo y opina que los autores (David J. DeWitt es coautor) es que los autores se han despistado y que si en lugar de hablar de MapReduce hubiesen hablado de Amazon SimpleDB el artículo hubiera tenido sentido. Hay también es más drástico y opina que StoneBraker ya no es una referencia para él.

Hay quien también apunta que el propio Google es consciente que el algoritmo no es lo mejor que podría ser pero que cumple su objetivo perfectamente. Otras comunidades y blogs como High Scalability, InfoQ o YComb se han hecho también eco del tema.

Lo cierto es que a mi también me ha chocado bastante la comparación entre MapReduce y una base de datos. Leyendo el artículo, la verdad es que uno sigue el hilo y hasta puede estar de acuerdo en algún punto de los puntos uno, y dos; pero es en los siguientes puntos, tres, cuatro y cinco, donde el artículo pierde definitivamente el norte.

A mi me da la impresión de como si durante estos años un montón de gente hubiese acudido a estas personas con preguntas del estilo "¿Por qué necesito una base de datos si Google no la usa?", "¿Tienen alguna base de datos como BigTable?", "¿Por qué va Google tan rápido sin base de datos y la que ústedes nos han recomendado va tan lenta?", y se hayan querido despachar a gusto. Realmente me suena a esto. A un "estamos hartos de tantos emails sobre BigTable y vamos a dejar las cosas claras".

En fin, la verdad es que los que nos manejamos a niveles muchísimo más modestos, pues por lo menos podemos intentar aprovechar estos lios para pillar un poco de aquí y otro poco de allá en los comentarios y aprender los entresijos de algunas tecnologías. Que al final es lo que vamos a sacar en limpio :-)

Una conversación sobre bases de datos

En ACM Queue publicaron hace unos meses una conversación/entrevista entre Michael Stonebraker toda una institución en el mundo de las bases de datos y Margo Seltzer cofundador de Sleepycat Software (Berkeley DB).

El artículo es uno de esos que lees y te quedas con las ganas de que siga, y siga, y siga. Buenísimo. Gira en torno al tema de que las bases de datos relacionales se han quedado obsoletas, y el actual escenario de motores gigantescos de bases de datos intentando acaparar mercados para el que no están preparadas. Temas como data warehouse, bases de datos en memoria para mercados financieros, por qué fracasaron las bases de datos orientadas a objetos, o la necesidad de cambiar el modelo de programación hacia lenguajes como ruby on rails son algunos de los temas que tocan.

No cuento nada más porque de veras que vale la pena leerlo.

Las claves en la arquitectura de base de datos de digg: memcached y sharding

Leo en ComputerWorld que el pasado Martes, Eliott White III estuvo hablando en la conferencia anual de MySQL. Ahí estuvo comentando algunos detalles interesantes sobre la arquitectura de digg que parece que ha llegado ya a los 1.2 millones de usuarios registrados. Me permito recapitular aquí algunos datos:

• 100 servidores desplegados sobre varios data center alojando 30 gb de datos.


• Un balanceador de carga que envia las consultas a servidores PHP. Servidores MySQL esclavos proveen de datos a los servidores PHP, mientras que uns ervidor MySQL maestro provee de datos a los servidores esclavos.


• Para evitar el sobrecargar la base de datos con consultas utiliza memcached. Memcached almacena porciones compactas de datos que se pueden utilizar para crear dinámicamente una página web. Esto lo diferencia de servidores de cache web tradicionales que almacenan la página completa. Otros sitios conocidos que utilizan memcached son Wikipedia, Sourceforge, Slashdot o Livejournal.


• Para hacer las consultas más eficientes hacen lo que se ha denominado recientemente como Sharding. Consiste en dividir una base de datos enorme en varias bases de datos más pequeñas de modo que el acceso sea mucho más eficiente. La base de datos se puede dividir por tablas, rangos, fechas, usuarios, etc. MMORPGs populares como EVE Online o World of WarCraft utilizan esta técnica para controlar las ingentes cantidades de datos que manejan.
  
  Los comentarios de White sobre Sharding son muy interesantes. Como bien dice, existen diferencias fundamentales entre particionar una base de datos y realizar sharding, siendo quizás la más importante que los shards suelen estar en máquinas diferentes, como sería por ejemplo el tener mundos diferentes en data centers diferentes en un MMORPG.
  
  White añade que el concepto de Sharding pone complejidad sobre el desarrollo ya que imposibilita el hacer operaciones habituales como joins sobre tablas.
  
  Aparentemente ingenieros de Google fueron los que acuñaron el término de Sharding. Este artículo en ZDNet muestra su uso dentro de su sección financiera. Hace poco Google contribuyó un proyecto de Shards en Hibernate.
  


• 20 servidores de bases de datos.


• 30 servidores web.


• Varios servidores de búsqueda ejecutando Lucene.


• Todos los servidores menos uno corren sobre MySQL 5. Los servidores con más carga transaccional así como las unidades de backup utilizan el motor InnoDB, mientras que los servidores OLAP utilizan MyISAM.


• Arquitectura inusual ya que el 98% de las operaciones son lecturas.

Interesante.